-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Orchestrator implementation #53
Conversation
* Return `Resource` rather than `Response` on fetch. Orchestrator needs the Resource object afterall in order to identify and notify watches. * Export `Resource` and `Response` members that will be used by calling classes. Signed-off-by: Jess Yuen <jyuen@lyft.com>
abd8b18
to
e2b47b1
Compare
Signed-off-by: Jess Yuen <jyuen@lyft.com>
e2b47b1
to
8c07603
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first pass looks great. This is a complex piece. Some questions.
Signed-off-by: Jess Yuen <jyuen@lyft.com>
Signed-off-by: Jess Yuen <jyuen@lyft.com>
Signed-off-by: Jess Yuen <jyuen@lyft.com>
Signed-off-by: Jess Yuen <jyuen@lyft.com>
Signed-off-by: Jess Yuen <jyuen@lyft.com>
Signed-off-by: Jess Yuen <jyuen@lyft.com>
Signed-off-by: Jess Yuen <jyuen@lyft.com>
Signed-off-by: Jess Yuen <jyuen@lyft.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some more questions.
Signed-off-by: Jess Yuen <jyuen@lyft.com>
Signed-off-by: Jess Yuen <jyuen@lyft.com>
Signed-off-by: Jess Yuen <jyuen@lyft.com>
To support per-key locking. Signed-off-by: Jess Yuen <jyuen@lyft.com>
Signed-off-by: Jess Yuen <jyuen@lyft.com>
Signed-off-by: Jess Yuen <jyuen@lyft.com>
Signed-off-by: Jess Yuen <jyuen@lyft.com>
Signed-off-by: Jess Yuen <jyuen@lyft.com>
Signed-off-by: Jess Yuen <jyuen@lyft.com>
@jyotimahapatra Addressed all comments, can you take another pass? |
select { | ||
case channel <- convertToGcpResponse(resp, *watch): | ||
break | ||
default: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How often is this expected to happen? It looks like this channel is buffered as 1. if there is spam of updates, maybe it is fine to drop?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's more discussion for this here.
The idea behind this was that a downstream receiver could be blocked for any reason. Initially I had went with a timeout, but in discussions with @jyotimahapatra we realized that it would imply the slowest sidecar would block new updates from being sent to other sidecars, due to the use of WaitGroups. We can't get rid of WaitGroups because more recent updates might get overriden by a slower update if updates were bursty.
The buffer is necessary in order to give time for the receiver to initialize. I realized in this test that the second watch (for the same aggregated key) would fall to the default
case if the channel was unbuffered.
If there is a spam of updates, I think it's reasonable to drop since only one of those updates will be applied downstream anyway, but we do lose the the guarantee that it is the "latest" update. Could move back to the configured timeout model if this is a concern, but I put some of those downsides ^.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My thoughts are to move forward with the default for now. I'll document this. If it is a problem in practice, then we can revisit the timeout model or other approaches.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah in the future, you can do what Envoymanager does and drop the oldest and enqueue the newest rather than logging an error.
That has been working quite well for us since none of the configurations requires ordering and we send the state of the world. We always just want the latest update.
Overall, this looks great. Most of my comments are around documentation of the code, but the logic of the implementation makes sense to me. I think it is fair to press forward. |
Signed-off-by: Jess Yuen <jyuen@lyft.com>
@jessicayuen The changes look great. I was thinking there's scope for adding some negative tests too for the orchestrator. If you want to add those in a separate PR, i would be ok with that. |
Signed-off-by: Jess Yuen <jyuen@lyft.com>
Signed-off-by: Jess Yuen <jyuen@lyft.com>
Signed-off-by: Jess Yuen <jyuen@lyft.com>
Sounds reasonable @jyotimahapatra, let me add that in a separate PR or as a part of the e2e tests - this PR is already getting a bit unwieldy and I would like to get a base point in. |
@lita I might be misunderstanding, there are some ordering concerns with ADS. There has been a few issues about it on the go-control-plane repo (one of them from myself). @kyessenov summarizes it best, union updates and version transactions: envoyproxy/go-control-plane#218 (comment) |
Add the end-to-end request management workflow.
See comments inline for details.
Three open issues to follow up on (also inline in code):
#71
#70
#68
Signed-off-by: Jess Yuen jyuen@lyft.com